IBIS Macromodel Task Group Meeting date: 03 May 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Ming Yan Radek Biernacki * Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang SAE ITC * Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Michael (Mike) McNair introduced himself. He is currently serving as VP for Aerospace at SAE ITC (IBIS's parent organization). He said his background was in systems engineering and embedded software. He had developed device drivers and other low-level software that was close to the hardware. He was joining to learn more about what we do. ------------- Review of ARs: - Michael Mirmak to create draft 2 of BIRD219.1 containing the meeting's changes and send it to the ATM list. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 26th meeting. Ambrish moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD219.1 draft 2 AMI Parameter Root Name Clarifications: Walter gave a general overview of ATM and this topic to help Mike McNair. He said there are three broad categories in the IBIS community: model makers, EDA tool makers, and end users/consumers. Walter said he had worked in all three areas, and that one persistent feature of ATM meetings is that model makers and tool vendors are generally better represented than end users. Walter said the issue at hand is what to do when an AMI model is not being used correctly. When the tool calls the model, it passes in a parameters string in AMI_parameters_in. When the model's call returns, it passes back a string in AMI_parameters_out. The root name of the strings should match each other and match the root name from the .ami parameters file. What should be done if they don't match? What should the model do if the tool passes in an unexpected root name? What should the tool do if the model passes back an unexpected root name? Arpad concurred with the summary and noted one additional point. In forward- looking discussions in the Quality task group, the idea of a .dll supporting multiple sets of functionality had been explored. In that scenario, the root name itself might serve an AMI Selector (analogous to [Model Selector]) in the future. Walter said the BIRD's author, Michael Mirmak, had run into difficulty with models doing strange things if they received an unexpected root name. He'd also found that tools may behave differently and produce different results if they received an unexpected root name back from the model. This BIRD wants the model and the tool to detect and report issues with the root name. Walter said that as a model maker he knows what he has to do. He has to return a message string in the msg parameter. Unfortunately, lots of messages could already exist in that string. So, he suggested we might put something special in the string (e.g., "*** Error ***") to make it clear to the EDA tool that a message requires priority handling. Arpad asked whether we should define a message numbering system similar to what the ibischk parser employs. Walter said he just wanted EDA tools and model makers to agree on a string identifier so the EDA tool knows how to handle/display the message. Arpad reminded everyone that at the previous meeting the obligation of the model to report any mismatch had been reduced from a requirement to a suggestion. He asked Ambrish to state his case again, as he had been the only one to oppose the requirement. Ambrish said that we should avoid legislating what tools and models "must" do unless it's necessary. He said some models may simply not care about the root name. They shouldn't be obligated to check if they don't care. We also don't need to standardize what type of message the model returns. He said there would be many places in the specification where we could do that, and it would open Pandora's box. Ambrish said that after last week's discussion we decided not to mandate that the model check. However, if the model does check and care about the root name, then it should report a message in the event that it receives something it doesn't like. The message should indicate what it does expect. Otherwise, the user has no idea why the model balked. Randy asked if this would be the first case of us specifying what the .dll's message should contain. Walter said that as a matter of course, all 7.2 models he creates will return a message if they detect a root name mismatch, and the message will have an indication that it's an error. Walter said if the model isn't required to return a message, then it wasn't worth trying to specify the contents. Randy said we could eventually create a whole guide to required message formatting/content, but it would be beyond the scope of this BIRD. After further group discussion, Walter said he was okay with the model not being required to check the root name and return a message. He said the tool could do the checking. The tool passes a root name in, and it gets a root name back. If there's a mismatch, the tool can check and catch it. Arpad asked if the tool could catch an issue in the case of a model that simply always returned the same root name it had received. Walter and Ambrish said this would be a clear indication of a model that did not care about the root name, and no checking was required. Arpad asked whether everyone agreed the current draft was ready to be submitted to the Open Forum. Randy moved to submit it to the Open Forum as BIRD219.1, with a minor grammatical changed noted during the meeting. Walter seconded the motion. There were no objections. - Walter: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. AR: Arpad to send the latest draft of BIRD219.1 to Randy to be submitted to the Open Forum as BIRD219.1. ------------- Next meeting: 10 May 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives